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[57] 



ABSTRACT 



A cryptography system architecture provides cryptographic 
functionality to support an application requiring encryption, 
decryption, signing, and verification of electronic messages. 
The cryptography system has a cryptographic application 
program interface (CAPI) which interfaces with the appli- 
cation to receive requests for cryptographic functions. The 
cryptographic system further includes at least one cryptog- 
raphy service provider (CSP) that is independent from, but 
dynamically accessible by, the CAPL The CSP provides the 
cryptographic functionality and manages the secret crypto- 
graphic keys. In particular, the CSP prevents exposure of the 
encryption keys in a non-encrypted form to the CAPI or 
application. The cryptographic system also has a private 
application program interface (PAPI) to provide direct 
access between the CSP and the user. The PAPI enables the 
user to confirm or reject certain requested cryptographic 
functions, such as digitally signing the messages or expor- 
tation of keys. 

49 Claims, 23 Drawing Sheets 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 Sheet 1 of 23 



5,689,565 




CREDENTIAL BINDING 
SERVER 



REGISTRATION PROCESS 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18,1997 sheet 2 of 23 5,689,565 




CREDENTIAL BINDING 
SERVER 

TRANSACTION PROCESS 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 3 of 23 



5,689,565 



REGISTRATION PROCESS 



GENERATE 
REGISTRATION 
PACKET 



50 



52 



SEND REGISTRATION 
PACKET TO BINDER 



54 



VERIFY REGISTRATION 
PACKET 



GENERATE 
CREDENTIAL 



56 



58 



SIGN CREDENTIAL 
WITH BINDER 
SIGNATURE 



SEND SIGNED 
CREDENTIAL TO 
PARTICIPANT 



60 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 4 of 23 



5,689,565 



GENERATE 
REGISTRATION 
PACKET (STEP 50) 



70 



GENERATE SIGNING 
PAIR OF PUBLIC/ 
PRIVATE KEYS 



72 



GENERATE KEY 
EXCHANGE PAIR OF 
PUBLIC/PRIVATE KEYS 



-f- 



74 



GENERATE DIGITAL 
SIGNATURE 



-A 



76 



ENCRYPT DIGITAL 
SIGNATURE WITH 
SIGNING PRIVATE KEY 



-f- 



78 



ENCRYPT PUBLIC 
KEYS AND DATA 
WITH SYMMETRIC KEY 



■A 



80 



ENCRYPT SYMMETRIC KEY AND 
CRITICAL ACCOUNT DATA WITH 
PUBLIC KEY OF BINDER 



-f- 



82 



PLACE IN 
COMMUNICATIONS 
PACKET 



4 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 5 of 23 



5,689,565 



VERIFY REGISTRATION 
PACKET (STEP 54) 



90 



DECRYPT SYMMETRIC KEY AND 
CRITICAL ACCOUNT DATA WITH 
PRIVATE KEY OF BINDER 



■A 



92 



DECRYPT PARTICIPANT'S 
PUBLIC KEYS AND DATA 
USING SYMMETRIC KEY 



94 



DECRYPT DIGITAL SIGNATURE 
USING PARTICIPANT'S 
SIGNING PUBLIC KEY 



96 



RECALCULATE DIGITAL 
SIGNATURE 



98 



COMPARE DECRYPTED SIGNATURE 
WITH RECALCULATED SIGNATURE 




12/18/04, EAST Version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 6 of 23 



5,689,565 



TRANSACTION 
PROCESS 



-A 



100 



SEND REQUEST FOR 
CREDENTIALS OF RECIPIENTS 



( 

RETURN CI 


1 <S 

1EDENTIALS 




.n 


VERIFY AUTHENTICITY 
OF CREDENTIALS 

^ 



102 



106 



CONSTRUCT DOCUMENT(S) 
AND INSTRUMENT(S) 



COMPUTE HASH FOR 
DOCUMENT(S) AND 
INSTRUMENTS) 



108 



110 



ENCRYPT HASH 
WITH ORIGINATOR'S 
SIGNING PRIVATE KEY 



TO STEP 112. FIG 7 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 7 of 23 



5,689,565 



FROM STEP 1 10, FIG 6 



112 



ENCRYPT DOCUMENT(S) AND INSTRUMENT(S) 
WITH SYMMETRIC KEYS 



■A 



114 



ENCRYPT SYMMETRIC KEYS AND 
CRITICAL ACCOUNT DATA 
WITH KEY EXCHANGE PUBLIC KEYS 
OF INTENDED RECIPIENTS 



4- 



116 



SEND SIGNED ENCRYPTED DOCUMENT(S) 
AND INSTRUMENTS) TO FIRST RECIPIENT 



118 



DECRYPT DOCUMENT OR INSTRUMENT AT 
FIRST RECIPIENT USING FIRST RECIPIENT'S 
KEY EXCHANGE PRIVATE KEY 



120 



VERIFY SIGNATURE USING 
ORIGINATOR'S SIGNING PUBLIC KEY 



122 



VERIFY AUTHENTICITY 
OF ORIGINATOR 



TO STEP 124, FIG 8 



7 



12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 8 of 23 



5,689,565 



FROM STEP 122, FIG 7 



-f- 



124 



PASS REMAINING ENCRYPTED 
DOCUMENT OR INSTRUMENT 
TO NEXT RECIPIENT 



126 



'decrypt document or instrument at 
next recipient using next recipient's 
key exchange private key 



128 



VERIFY SIGNATURE USING 
ORIGINATOR'S SIGNING 
PUBLIC KEY 



130 



VERIFY AUTHENTICITY 
OF ORIGINATOR 



, LAST \J32 
RECIPIENT 
PARTICIPANT 



YES 



134 



RETURN RECEIPTS 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 9 of 23 



5,689,565 



142 

t 


144 

i — A— — | 




146 

—f 




TAG 


LENGTH 












VALUE 














j 



W*9 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 10 of 23 



5,689,565 



152 



A 



154 



NETWORK I/O PORT 



156 



1£ 



PROCESSOR 



150 



A — J 



158 



DATA INPUT /I — ) 
APPARATUS \ . 



3 



160 



CARD READER 



A ' 

v- 



MEMORY 



COMMERCE APPLICATION 



CAP/ 



BINDER'S PUB KEY 



CSP VERIFIER 



CSP 



BINDER'S SIGNATURE - 



KEY MANAGER 



SIGNING PUB/PR/ KEYS- 



KEY EXCHANGE 
PUB/PRI KEYS 



SYMMETRIC KEY 
GENERATOR 



SYMMETRIC KEY 
ENCRYPT/DECRYPT 



ASYMMETRIC KEY 
ENCRYPT/DECRYPT 



HASHING CALCULATOR - 



SIGNING DEVICE 



162 

172 
180 



181 

174 

V 

179 
182 
184 
186 

188 

190 

192 

194 
196 

176 



PARI 



22 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 11 of 23 



5,689,565 



170 



162 



APPLICATION 



172 



CRYPTOGRAPHIC APPLICATION PROGRAM INTERFACE (CAP/) 



174(a) 



CSP 



174(b) 



CSP 



174(c) 



CSP 



v ^l76(a) i 



J \~ 



174(d) 



CSP 



J v. 



PRIVATE 
API 



76(b) „ 176(c) „ ^ 176(d) 
/ *—r — \ /• r \ 



PRIVATE 
API 



PRIVATE 
API 



PRIVATE 
API 




USER 



Mm 11 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 12 of 23 



5,689,565 



ENCRYPTING AND 
SIGNING 



200 



SEND PLAINTEXT MESSAGE 
TO CAP! 



202 



SELECT CSP 



204 



ESTABLISH COMMUNICATION 
BETWEEN CAPI AND CSP 



-A 



206 



VERIFY AUTHENTICITY 
OF CSP 



208 



PASS PLAINTEXT MESSAGE 
FROM CAPI TO CSP 



-A 



210 



HASH MESSAGE 



212 



SUPPLY EXPLANATION 
TO PARI 



TO STEP 214, FIG 13 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 13 of 23 



5,689,565 



FROM STEP 212, FIG 12 



214 



PRESENT EXPLANATION 
TO PARTICIPANT 



216 



RETURN CONFIRMATION 
FROM PAPI TO CSP 



-f- 



218 



DIGITALLY SIGN 
MESSAGE AT CSP 



-f- 



220 



GENERATE SYMMETRIC 
ENCRYPTION KEY 



-f- 



222 



ENCRYPT HASH DIGEST AND DIGITAL 
SIGNATURE WITH SYMMETRIC KEY 



224 



ENCRYPT SYMMETRIC KEY WITH 
PARTICIPANT'S PUBLIC KEY EXCHANGE KEY 



TO STEP 226, FIG 14 



12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 14 of 23 



5,689, 



FROM STEP 224, FIG 13 



226 



PASS SIGN ENCRYPTED MESSAGE 
FROM CSP TO CAP/ 



228 



INFORM USER AT PARI OF 
EXPORTED SYMMETRIC KEY 



J 




12/18/04, EAST Version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 15 of 23 



5,689 



DECRYPTING AND 
VERIFYING 



-f- 



250 



SEND ENCRYPTED MESSAGE 
TO CAPI 



-f- 



252 



SELECT CSP 



-f- 



254 



ESTABLISH COMMUNICATION 
BETWEEN CAPI AND CSP 



256 



VERIFY AUTHENTICITY 
OF CSP 



258 



PASS ENCRYPTED MESSAGE 
FROM CAPI TO CSP 



260 



DECRYPT SYMMETRIC KEY WITH 
PARTICIPANT'S PRIVATE KEY EXCHANGE KEY 



-f- 



262 



DECRYPT MESSAGE 
WITH SYMMETRIC KEY 



TO STEP 264, FIG 16 



0^ US 



12/18/04, EAST Version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 16 of 23 5,689,565 



FROM STEP 262, FIG 15 



264 



VERIFY PACKET WITH 
DIGITAL SIGNATURE 



266 



RETURN PLAINTEXT MESSAGE 
FROM CSP TO CAPI 



■A 



268 



DESTROY SYMMETRIC 
ENCRYPTION KEY 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent 



Nov. 18, 1997 



Sheet 17 of 23 



5,689,565 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 



Sheet 18 of 23 



5,689,565 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 19 of 23 5,689,565 



r 350 

' — \ 



PURCHASER APPLICATION 



^352 

~r—\ 



PURCHASER API 



A 72 



CRYPTOGRAPHIC APPLICATION PROGRAM INTERFACE (CAP!) 





12/18/04, EAST Version: 2.0.1.4 



U.S. Patent Nov. 18,1997 Sheet 20 of 23 5,689,565 



354 



MERCHANT APPLICATION 



,356 
-r—\ 



MERCHANT API 



A 72 



CRYPTOGRAPHIC APPLICATION PROGRAM INTERFACE (CAPI) 



12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18, 1997 Sheet 21 of 23 5,689,565 



.360 



ACQUIRER APPLICATION 



.362 

f \ 



ACQUIRER API 



A 72 



CRYPTOGRAPHIC APPLICATION PROGRAM INTERFACE (CAP!) 




12/18/04, EAST version: 2.0.1.4 



U.S. Patent Nov. 18,1997 sheet 22 of 23 5,689,565 



364 



BINDER APPLICATION 



^566 



BINDER API 



172 



CRYPTOGRAPHIC APPLICATION PROGRAM INTERFACE (CAP!) 




12/18/04, EAST Version: 2.0.1.4 



. Patent Nov. 18, 1997 Sheet 23 of 23 5,689 




12/18/04, EAST Version: 2.0.1.4 



5,689,565 

1 2 

CRYPTOGRAPHY SYSTEM AND METHOD Encryption, decryption, digital signing, and verification 

FOR PROVIDING CRYPTOGRAPHIC are principal cryptographic primitives that are used in an 

SERVICES FOR A COMPUTER electronic network setting to facilitate the security, privacy, 

APPLICATION authenticity, and integrity of information being exchanged. 

TPriTMT^Ai xttot i» * c^Ptographic prirnitives commonly involve the use 

i ttcnmuAL held of secret cryptographic keys. "Keys" are a numerical value, 

This invention relates to cryptography systems. More often expressed digitally as a number of bits, which arc used 

particularly, this invention relates to a computer imple- in * c cryptographic algorithms that encrypt and decrypt 

mented architecture for performing cryptographic primitives messages. The keys are uniquely associated with a particular 

including encrypting, decrypting, signing and verifying/ io ide . DUt y' sucn & a person, group, physical object, business, 

authenticating functions. or institution. The keys are kept secret and used selectively 

^ by the identity to perform the cryptographic primitives as 

BACKGROUND OF THE INVENTION required. For example, a person might use a key to encrypt 

Cryptography is the an and science of keeping messages aBd si S n a Purchase order message intended for a merchant 

secure from eavesdroppers and adversaries. Historically, 15 Tne merchant might then use a key to decrypt the message 

valuable messages were kept secure by personal envoys who verify the authenticity of the signature, 

hand carried sensitive information from a sending party to a 10 a network setting, it is desirable to locate cryptographic 

receiving party. While useful in its time, this protection functions in the computer operating system so that they are 

method is not very practical in a modem world where available to other applications executing on the computer, 

information flows freely and changes rapidly. ^ Furthermore, it is desirable to define an application program 

In more recent history, with the advent of computers, interface (API) which allows the applications access to the 

wireless communication, and other technological advances, cryptographic functions in a staridardized way. 

information can be exchanged very quickly among many A cryptographic API raises a number of important secu- 

different individuals who were often spread all over the nty issues. Cryptographic functions, such as encryption and 

world. To provide a secure interchange of information in the 25 s ^8 nm 8* C2in performed using a number of different 

electronic arena, one traditional approach to mitigating the algorithms and formats. Security can vary widely among the 

risk of having sensitive information intercepted was to different approaches. A single module of the operating 

institute proprietary computerized systems mat were closed system cannot possibly implement all possible algorithms 

to the general public. Such proprietary systems promoted anc * formats that a user or application might want to use in 

security simply by restricting physical access through high 30 a P VCD situation. 

security protocols. A private communication network linked On the other hand, cryptographic functionality involves 

only those terminals that were authorized, and only partici- the handling of sensitive information and the maintenance of 

pants to the system with the appropriate security clearance secure keys. It would be advantageous for a user or appli- 

were permitted access to the terminals. Hence, participants cation to be able to trust the cryptographic system on the 

and information were authenticated by definition, and the 33 same level mat an operating system is typically trusted, 

integrity and value of the information were preserved within There are also potential hazards of using cryptographic 

the confines of the closed processing system. Unfortunately, functions in the computerized network setting. Since the 

proprietary systems are not useful in a grander context functions are carried out electronically, the user might 

which envisions the interchange of information among vir- assume the cryptographic routines are operating as expected, 

tualiy any individuals without limitation. 40 yet not be aware of ignorant or sophisticated electronic 

Cryptography has evolved in the electronic setting as a attacks. Careless applications might use cryptographic 

means to securely transfer information over a communica- encryption or signature keys in ways that jeopardize the 

tion system that is presumed to be insecure, like the tele- keys' secrecy. Moreover, malicious applications might even 

phone lines or a public communications network (eg., the deliberately compromise the user's secrecy, or worse, per- 
Intemet), In this electronic computerized context, cryptog- 45 form unauthorized cryptographic operations. For instance, a 

raphy provides the necessary tools to digitally secure sen- malicious application might attempt to decrypt the user's 

sitive and valuable electronic messages in a manner that secret files and transmit them to some advene party. Another 

insures privacy between the authenticate sender and authen- situation might involve an application attempting to digitally 

ticate recipient of the communique, even though the mes- sign notes or IOUs on behalf of the user without the user's 
sage is subject to interception on the insecure communica- 50 knowledge or consent A computer implemented crypto- 

tion system. graphic system must therefore provide the needed security to 

Before sending an electronic message, the sender encrypts prevent attack from poorly devised or malicious applica- 
nt- "Encryption" transforms the message from its plaintext ^ons. 

into some meaningless ciphertext that is not understandable Today, there are several electronic systems that provide 
in its raw form and cannot be deciphered by an eavesdrop- 55 cryptographic services in the computer forum. These include 

per. To ensure the recipient that the true sender originated the "Bsafe libraries" by RSA Data Security Inc., "X/Open 

message, and not some impostor, the sender "digitally signs" CAPr, and "PKCSr\ However, each of these systems 

the message with its own unique digital signature. The permit direct access of the application to keying material, 

signed encrypted message is then transmitted over the There is no protection of these cryptographic resources from 
insecure network to the intended recipient. The recipient 60 electronic attack. Furthermore, the Bsafe system, which is 

receives and decrypts the encrypted message. "Decryption" the most widely used cryptography system, directly attaches 

transforms the message from its ciphertext back to its the cryptographic code to the application. There is no 

plaintext Only the recipient is presumed to have the ability conternplation of protecting the cryptographic functions 

to decipher the message. The recipient also 'Verifies" the within the computer from ignorant or malicious attacks from 
authenticity of the digital signature to assure itself that the 65 other software applications. 

contents are from the legitimate sender and have not been It would therefore be advantageous to provide a computer 

subsequently altered. implemented architecture for performing cryptographic 
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primitives that maintains and protects the user's keys and cryptographic functions themselves and the associated secu- 

prevents undesired access and use of cryptographic func- rity levels can be easily modified or replaced without 

tions without authorization from the user. affecting the higher level application. This is useful for rapid 

conformation to acceptable and changing regulatory and 

SUMMARY OF THE INVENTION 5 legal practices imposed by various governments. Finally, by 

This invention provides a cryptographic system and providing the PAH layer the architecture protects the user 

Zp^Jl user's keTaaTSveuts^ndesired *™ ^licious ^^0^^^ 

access and usVof cryptographic functions without authori- information or gam unauthorized signatures of the user. 

zation from the user. The cryptographic system is a unique BRIEF DESCRIPTION OF THE DRAWINGS 

tri-layer architecture. It includes a cryptographic application 10 

program interface (CAPI) which provides functionality to an FIG. 1 is a schematic of an electronic commerce system 
appHcation, one or more cryptographic service providers during a registration process according to one aspect of this 
(CSPs) which implement the functionality presented by the invention, 

CAPI to the application, and one or more private application FIG. 2 is a schematic of the electronic commerce system 
program interfaces (RAPE) which allow the CSPs to com- 15 during a transaction process according to another aspect of 
municate directly with a user. this invention. 

The CAPI layer provides the interface with an application FIG. 3 is a flow diagram of the registration process in a 
that requests cryptographic functions such as encryption, method for conducting an electronic commerce transaction 
decryption, signing, or verification. The CAPI selects the ^ according to yet another aspect of this invention, 
appropriate CSP for performing the requested cryptographic pj G 4 ^ a fl ow diagram of a process for generating a 
function. The CSPs perform the cryptography functions and registration packet that is performed during the registration 
manage the cryptographic keys used in the functions. For process. 

instance, one or more CSPs might be configured to perform H G 5 is a flow diagram of a process for verifying a 
the encryption function using certain types or cryptographic ^ registra ti 0 n packet that is performed during the registration 
algorithms and keys; one or more different CSPs might be process ^ 

e^to^ FIGS . 6-S P-nt a flow dia^am of 

STS designed to verify signatures and messages. process in the method for conducting an electronic com- 

Preferably, the CSPs are implemented as dynamic linked merce transaction. 

libraries (DLLs) that are loaded on demand by the CAPI. 30 FIG. 9 is a data structure used in the interchange of data 
and which can then be called by the application through the between participants in the electronic commerce system. 
QAFl. FIG. 10 is a block diagram of a computing unit provided 

The CAPI also authenticates the chosen CSP. Each CSP at each participant in the electronic commerce system, 
has a digital signature of a trusted authority which can be 3J ^IG. 11 is a block diagram of an architecture for a 
authenticated by the CAPI to ensure that impostor CSPs are cryptography system according to yet another aspect of this 
not introduced to the system invention. 

To promote security, the application is restricted from FIG. 12-14 are a flow diagram of encrypting and signing 
direct access to the cryptographic keys maintained in the functions performed by the cryptography system. 
CSPs, but is permitted to manipulate the keys through the ^ pj G are a flow diagram of decrypting and verify- 
use of handles assigned by the CSPs. Cryptographic keys fu nctions performed by the cryptography system, 

used in the encryption and decryption are not exported from HG 1? . g a 3^^^ Q f electronic commerce system 
the CSPs in their raw form, but only in an encrypted form embodied as a credit card system according to another 
Moreover, certain confidential private keys are not permitted of ^ fjq. 17 shows the credit card 

to leave the CSPs under any circumstances. In this manner, 45 ^ b d . ^ rcgistia tion phase, 
the CSPs protect the toys from compromrse while sum*- > 18 is a schematic of the credit card system during the 
taneously offering a full range of cryptographic functionality ^^Cllon^c 

thxthtusvfwKctaonreqvests. th . FIGS. 19^-22 are block diagrams depicting the FIG. 11 

The PAPI keeps the user uiformed as to the f unctions as to operating system appli- 

being performed by*e «Ps. TTie PAP ^des toe user 50 ^^^nt at a meVchant, acquirer, and 

with direct access to me CSP. ind^ndent of ^ whcaUoa to £^ nGt 18 ^t card system. 

The PAPI can present information to the user that the user uulua *^ ^ . . . _ . 

may n1TS*e application to provide. For instance, the WG »^ as ^ cof *^ e ^ mC ~ZT^S 
3 can present trough the PAPI an explanation of the embodied as an interacttve entertainment system according 
transaction being conducted by the CSP. The CAPI might „ to yet another aspect of this invention, 
also present a dialog box asking for the user's confirmation DETAILED DESCRIPTION OF THE 

each time an application requests a digital signature to PREFERRED EMBODIMENT 

enable the user to confirm or reject digitally signing the L ^ 

message The PAPI might also be configured to notify the The following discussion assumes that the reader is 
user and seek permission to export certain cryptographic eo familiar with cryptography. For a basic introduction of 
l^yj cryptography, the reader is directed to a text written by 

This system architecture can be advantageously adapted Bruce Schncier and entitled "Applied 
to many different environments. By implementing the cryp- Protocol. Algorithms, and Source Codein C. Pushed by 
togra^cservicesasindependentandseiwrateCSPsthatare John Wiley & Sons with copyright 1994. which is hereby 
only accessible through a CAPI layer, the architecture 65 incorporated by reference. 

affords maximum protection of sensitive cryptographic This invention particularly concerns a cryptographic sys- 
keys Additionally, by implementing the CSPs as DLLs, the tem architecture and method for providing cryptographic 
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To ™!Z , UOn V E^rnple certifying authorities in die financial environment 

To provide an example context however, aspects of this include the federal reserve or a bank The MmESS 

invenuon are described in the context of an electronic ronment in which the efcoronic commaS m^TirX" 

SZf^^ mW ^ Chf ^ teteStoesecmeintcrch4n 6eof mented defines the rules an KSS?r225 o^£ 

commercial documents and instruments over an insecure 10 out the transactions, and additionally defmeTwho or X 

communication system. By describing the invention in a entity is the certified trusted wftS 

Particular example context, the reader wfll apcreciate how Th, .„ .2. 

the unique architecture and methodolog7caTbt^Z i„*£l*t ° ■ "T 20 030 1,6 

rated into a practical setting. From this the readeTwK£ ° (LffCrent environments - «ample. the electronic 

understand the invention atd how ^can 2 .5 SSSX^Si^^ h " «* 

essentially any electronic environment whichhas need fa "^f..?* electtonic commerce system employs 

cryptographicfunctions.ThefoUoXg SoosSSSS m^S^^^S ^ and CTedit «"> «"»■ 

example context of an electronic commerce raterT meroe structure, while broadening access to that system to 

ElaloniP r™™. e. / rommcrce systenL individual consumers. This example implementation is 

hSTh *T ? m • *, dCSCribed bel0w 10 mQre d«aU^A reference to HGS 17 

JSi« ^ M electromc commerce system 20 for 20 and 18. As another example, the electronic commerce sys- 

conduenng secure electronic commerce transactions. The tem can be implemented in an interactive entertainment 

electronic commerce system 20 includes multiple trading system which supports set-top boxes in each subscriber's 

fanners or participants, which are represented by three home. This example implementation is described below in 

parucipants 22(a). 22(6). and 22(c). and a certified trusted more detail with reference to FIG 23 

SS?, T IMdU " 1 dCCtr0,,iC COmmerce M ^ electronic commerce system 20 facilitates the secure 

Scomm^cc SZ.'rr"^ "'T"" *' lea * exd,an « e of documents acd «rce 

^=njt« 30 s^.i,S p g ^\S=3HE 

defines amode of paymentfor the transaction. Examples of messages from other V^S^l^TiZ\t^ 

Computing units 24(«). 24(6). and 24(c) are provided at « General Operation 

mM®.compatible personal ^mputXTtSouT^ * 1^1" COmmerce s y stem t0 I"™** *« 

forms of computing's may boused. For iSce S F^l^TtlST*^ V" ^ mUSta,ted ta 

computing units might be embodied as conventional com! ™S ■ ' \ T registration process in which each 
puters (such as mainframe co^uTers £r?er^ PCsU^ 40 ?5 tici P ant <* *« certified trusted authority. 

notebooks.etc.)craso*w^^^^ Jl^ 0 ^ ^ Z^*,*" 1 * na Z is a 
banking ATMs (automated STSSSSiS ^ ^ 8eneraJ document and 

boxes used in an interactive SioTsyS. ^ ment mtercliange among the various participants. 

A computer server 28 is provided at the certified trusted « JJ&SSSff^ * e 
authority 26. In the commercial context the certfied Ousted 45 ( at 11,6 pamcl P ants 22(«)-22(c) are each 

authority is often referred to Jj.^SSSSSJ?- w "J*"™* ^ 8 "t^*™ ova 

ing authority," or simply "binder." Thelerver 28 is tous , T^f™ SyStem (as re P resented ^ communica- 
referred to herein as* "aedSial TbfnS *£er" S ^^^Wftateatto^bhtilag server 28at 
computer server is capable of receivi^shSanelJs M ^X^ "^"'^ ^ 
requests from the multiple participants, as will bed«cribed * " P TT 1 ,0 P roduce uni ^ ue credentials for 

in more detail below ascribed each participant based upon their registration packets and to 

The computine units 2Ma\ »nrf ^ ,»h . f end 11,6 aedentkls 32 < fl )^2(c) back over the communica- 
nc OTmpuong units 24(a). 24(6), and 24(c) and computer tion system (as represented bv communieatifwi nathc 

~^on "T 11 ^ 111 " Ch Vk 0DC °^ 0rc -34(c)) to the multiple Z^tiZ^^ZlT) 

£^^ 0a SyStcm f' 11,6 communication systems can 55 credentials are digLly Sed by fte^Tsted^ 

be embodied as a wue-based or wireless network. Examples authority and wiuKd SJSv and SSnticlSh^ 

•participanr can be ShSSS^ ^SL^H " SJSSiSKE Z?" ,0 ^ ^ 3 . tnlStCd 
card holder, an ITV viewer, or a^okin member att' ^"S^ ^ 
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Each commerce transaction has at least one originating In this manner, each ^^^^^-tdfeck 

participant and one or more recipient participants. A com- dealing with an authenticated party, "***>^** ~ 

outinTunit 24(a) at the originating participant 22(a) Is with the trusted authority each tune. Further, the first party 

£o£am£Jd l! ^^tranXiveVVaedentials of aU can confirm that the goods/services can be sent/rendered 
intended recipient computing units 24(b) and 24(c). The s before involving the bank. 

originating computing unit also verifies the credentials by n,e electronic commerce system and method for operat- 
checldng the digital signature of the trusted credential i ng it w flinow be described in more detail with reference to 
authority. The originating computing unit 24(a) then gener- pj 0S 1-g ^ registration process is described with rel- 
ates commerce document(s) 36 and commerce instruments) ercQce to pjQ 1 ^ mc flow diagram of FIGS. 3-5, and the 
38 that are appropriate for the type of commercial transac- 1Q ^^^n process ^ described with reference to FIG. 2 and 
don. The documents) and instruments) are both encrypted fte flow < ^ agfam FIGS. 6-8. 
and sent together over a communication path 40 to .the Re(rfstration ^0,^ 

computing unit 24(b) at the first recipient participant 22(b). ^^T 1 . m/m and 22(c) is required to 

whom the document) or instrument(s) pertains can decrypt fj^f^^ ^TZlves communication over 

them " . . • t -,^i inm0 r»m m edto the communications system between each participant and 

The first recipient Wtmgumt 24(b) £ £^ trusted autfiority as illustrated in FIG. 1. Each 

decrypt either the commerce document(s) 36 or te com . - ^ generates a registration packet containing gen- 
merce instruraent(s) 38 depending^ w^ch one(^ 20 ^^SaSu, ^participant (step SO in FIG. 3). 

intended for and pertains to them. The first recipient com- erai uu r commerce environ- 

puting unit 24(b) men passes the <^'>^«?S ^F^T^TtoVp**^ to assist them in 

documents) 36 or the commerce instrument(s) 38 .n mcmcan ^ £ ormation required by the 

pertaining to them. . . „ f . a „„„„„ pr G 4 shows ^ method for generating the registration 

As an example, the originating participant is a consumer. g", referred irnplementatioa. At steps 70 
the first recipient participant is a merchant. *> ^"J^JS^Sft genaL two asymmetric pairs 

recipient participant is a financial u^uonj^ a bant an ^JJJgS^^ keys. An "asymmetric" 

The commerce document 36 is a purchase ota from ihe of P^^^eUw^Sate keys, for example, one 

consumer to buy goods or services from the merchant. The key „' S e ^° ^LL 7^ based 

commerce moment 38 is a payment instruction to the ^^^J^^T^ cannot 

merchant. The bank's computing unit 24(c) decrypts the ErUtf)=u - 
commerce instrument (i.e.. the payment instructions) which 40 w ^ 

pertains to payment for those goods or services. For added D^*{uyM 

So^SextJthe syrSickey used to encrypt me "Kpri" «M" is . plaintext rnessage. ILJl.^^SS 

rest ofme payment instruction). 45 version of the p aintext ^^IP^f * 

ering the ordered goods and services. g~"»a£ assured that the message was 

The electronic commerce system of this invention is ss key^tnat party originated with 

advantageous because it opting J^^^S*^**^^* 

cation between the participants. During the iransactioa.the «"^^JJJ rfc ^ ^ ^ wcU .known RSA crypto- 

originating participant sends one g^«££ *£ ^5S£2d for the creators Rivest, Shamir, 

the document and instrument to the same recipient, ine ^f~r 

document and instrument are encrypted differentty so that «o and Adtanan. computing unit generates a 

only me intended recipient -J^^^ ^X^vS^iS^pi^^^ 

promotes security. The first recipient (lecrypts mat , poraoa Mg transactions to generate the 

pertaining to «^-*^ *^£S£S ^It^Stafsignature by encrypting ^output of a 

recipient. Again, the first recipient only sends a paotage k> {~"7^ oi TT; the computing unit generates an 

one party. It is further noted that each P^-p^t can venfy 65 J-JJgJ^Sj ^T^buc and private cryp- 

the contents using the digital signatures of the originating fs^ 6 ™ ~ k ev Jchanee^air is used during me 

participant, and the digital signature of the trusted authority. tography keys. The key exenange pair useu g 
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commerce transaction to encrypt keys that in turn are used Eu*^**JK,-t=fC 

to encrypt data contained in the messages. °" 

At step 74, the participant generates a digital signature Notice that the data encryption process involves a dual 

that is unique to the participant and to the message. The encryption technique: a first encryption of data using the 

digital signature is computed by hashing the data contained 5 s y nunetric *ey. and then a second encryption of the syro- 

in the registration packet A hash function is a mathematical metric key using an asymmetric key pair. This dual encryp- 

function that converts an input data stream into a fixed-size, tion affords the desired security through the use of a strong 

often smaller, output data stream that is representative of the asymmetric key pair, while facilitating encryption of bulk 

input data stream. Once the hash is computed, it is encrypted us "*g mc more efficient symmetric key. 

by the computing unit with the private encryption key of the 10 At ste P 82 FIG. 4 « the computing unit places the 

signing pair (step 76 of FIG. 4). This is represented as encrypted data, digital signature, and public keys in a 

foUows: communications packet. The communications packet is suit- 

f /hq v-^c aWe for me appropriate communications system supporting 

*c*^cW<*W=dS^ the electronic commerce system 20. Preferably, the commu- 

where the **E W denotes an encryption function on the hash of ^ ^cations packet is in the form of individual digital data 

the message "dS " and the subscript "Ksign^pri^parT s *uctures that contain the appropriate routing information to 

means the participant's private key of the signing pair was efficiently locate the intended recipient 

employed to perform the encryption. By encrypting the f cfcrencc again t0 *IG. 3. the next step 52 in the 

participant's signature with its own private signing key, the registration process is for each participant computing unit 

eventual recipient will be able to verify the participant's *> ^ to its completed registration 

digital signature by decrypting the hash using the partici- Pf**?* 10 * e credential binding server 28 over the commu- 

pant'spubhcsigiimgkey,^^ nications system. This step is represented graphically in 

of the original message, and comparing the locally com- *?, 1 by ^^unication paths 30(a)-3<Kc) from the par- 

puted hash with the decrypted hash. The comparison win ud P ants 22{o>-22(c) to the certified trusted authority 26. 

succeed only if the participant's private signing key was 25 At step 54 in FIG. 3, the credential binding server 28 

used to encrypt the hash. Since only the originating partici- verifies ^e authenticity of the registration packets as being 

pant knows the private signing key, the recipient knows that sent by * c Participants. The verification process itself is 

the originating participant actually created the encrypted described in more detail with reference to FIG. 5. At step 90, 

hash, essentially "signing" the document c^ntial binding server 28 decrypts the symmetric bulk 
At step 78, both public keys of the signing pair and the 30 jf** encryption key K.^ using its own private key as 

key exchange pair arc encrypted with a symmetric cipher foUows: 

using a randomly selected bulk data symmetric encryption D Jfr *_ r 

key. In a "symmetric" cipher, the encryption key can be «*ro^*w a 'W 

calculated from the decryption key, and vice versa. In many Once the symmetric key is recovered, the credential 
cases, the encryption key and the decryption key are the 35 binding server 28 uses it to decrypt the participant's public 

same. Encryption and decryption using a symmetric key can keys and other data contained in the registration packet (step 

be represented as follows: 92 in FIG. 5). This can be shown as: 

****** D^^JPrtUr^ K«^+^ 

Dg(Afy=M 40 

Next, at step 94, the credential binding server 28 decrypts 
where "E/* is an encryption function using the symmetric t^e hash of the participant using the recovered participant's 
key "KT and "D K n is the decryption function using the same P" 01 ^ signing key, K £ign _ put ^ parr This yields the hash, dS, 
encryption key "K". The symmetric key must be known to 45 computed and concealed (encrypted) by the originating 
both the sender and receiver, but otherwise kept secret Once 45 participant: 
the symmetric key is divulged, any party can encrypt or 

decrypt messages. Example symmetric ciphers are a DES ^1^^^/^)=^ 

ESr yPti ° D enCryPti0n SU6 ° rithm ° ranRC4 ^ credential binding server 28 then performs a two-step 

Z7^T^ c :^n^ etliC eDayPd ° D ^credential bEg^Ter MrSZt'S 
keys. Mep 78 is represented as follows: pant . 5 4^ dgnaturc by ^ ^ aMaim ^ ^ 

Errata, K Mt ^_ puk _ p ^ v K*^_ r +_ p ^Dat*-& K' decrypted registration packet using the same hashing func- 

u/hm. «p - ic •».<.- ~, « a • . ... tion employed by the participant The recalculated hash is 

ricEl encrypuonfancaon using the symmet- 55 then compared with the decrypted hash received as a digital 

X£ o^'^d-K" 18 ^bhekeyoftoe signature, i.e.. privately encrypted hash, in the registration 

kSrf ? ite^t£s^r P""*"* 1 P ubUc P ackct (** W in HO. 5). If the two hashes match, the 
f*r ^l 8 P C u credential binding server is assured both that the registration 

com^SlKr,° n0f ?^^" Ctey(WteyS) - ,hC p8Ctet Was **** **** ^ fte Participant and STE 
ZZ? ^ 8 u * e reglStenne P^cipant encrypts the 60 contents have not been subsequently altered 

a^f^r 8 ^ aSymmCtti . C Rctonin 8 ° ncc "gain to FIG. 3. after the credential 

IJ^Z "^P*™ ** y 0 TT ,0 the bindin 8 server 28 verifies the registration packet as bdong 

wiU be ab e to decrypt the symmelnc key. and hence the rest 65 credential binding server 28 generates the credential Rach 

of the registration packet The encryption of the synunetric credential is uui£eT? P ^^^ 

key is represented as follows: used in future transactions as a rJans faScSJC 
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participants and for authenticating the participants to each 
other. The credential contains the participant's public sign- 
ing key, public key exchange key, unique identifiers, validity 
dates, owner infonnation, issuer information, and informa- 
tion about the participant determined in advance by owners 
and controllers of the particular commerce environment. 

At step 58, the credential binding server 28 attaches a 
digital signature of the trusted credential authority 26 to the 
credential. The digital signature is generated by encrypting 
a hash of the credential using the private key of the trusted 
credential authority 26. The binder* s digital signature will be 
used by the participants during transactions to verify that 
communications are between authorized participants who 
have properly registered with the trusted credential author- 
ity At step 60, the signed credential is transferred from Ac 
credential binding server 28 back over the communications 
system to the individual computing units 24(a), 24(fe), and 
24(c) at respective participants 22(a), 22(b), and 22(c). The 
is illustrated in FIG. 1 by the signed credentials 32(a>-32(c) 
being returned to the computing units along communication 
paths 34(c>-34(c). 

Transaction Process 

Following the registration process, the participants are 
ready to conduct their commercial activity. Unlike the 
registration process, however, the transaction process 
involves communication only among the participants to the 
transaction. There is no interaction between any of the 
participants and the trusted credential authority. 

As shown in FIG. 2, the commerce transaction process 
concerns the interchange of documents and instruments by 
participants, such as the representative three participants 
22(a)-22(c). The number of participants involved in a 
commerce transaction, the nature and content of the docu- 
ments and instruments, and the exchange protocol are all 
defined in advance according to the particular commerce 
environment. Here, the participants 22(a)-22(c) interchange 
information over the one or more communication systems 
between them, as illustrated by the pairs of arrows, without 
involving the credential authority 26. 
All commerce transactions have an originating 



At step 106, the originating participant 22(a) constructs 
the appropriate commerce document and commerce instru- 
ment for the commercial transaction. A commercial trans- 
action might involve more than one document or instrument, 

5 but for simplicity of discussion, our example transaction 
involves one document and one instniment. At step 108 in 
FIG. 6, the originating computing unit 24(a) computes the 
hash of the document and instrument through use of a 
hashing algorithm. At step 110, the originating computing 

10 unit 24(a) encrypts the hash using the private signing key of 
the originator's signing pair of asymmetric keys, as follows: 



15 



20 



Next, at step 112 in FIG. 7, the originating computing unit 
24(a) generates symmetric bulk data encryption keys and 
encrypts the document and instniment using the symmetric 
keys. Preferably, the document is encrypted with one sym- 
metric encryption key and the instrument is encrypted with 
a different symmetric encryption key. The encrypted hash. 
dS' n attached to the document and instrument as a 
di^taT'signature is also encrypted using the symmetric 
encryption keys. The bulk encryption step is represented as 
follows: 



25 
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f )=doctKDenf 
f )=instriMneot'. 



At step U4 in FIG. 7, the originating computing unit 
24(a) encrypts the symmetric keys with the public key 
exchange toys of the recipient participants that are intended 
to receive the document and instrument. For example, 
suppose the commerce document is a purchase order that is 
intended for the first recipient participant 22(b). who is a 
merchant Further, suppose the commerce instrument is a 
payment instruction that is intended for the second recipient 
participant 22(c), which is a bant The originating comput- 
ing unit 24(a) encrypts the first symmetric key used to 
encrypt the document (i.e., purchase order) and originator's 



All commerce transactions 1 °^" a "°| ^ ^^signature with the first recipient's (Le., merchant's) 
participant, which is represented ^ P^pmrm^ "* 40 JL. J, fom its key exchange pair of asymmetric keys. 



one or more recipient participants, which are represented by 
participants 22(b) and 22(c). The originating participant 
22(a) is the one who initiates a commerce transaction. The 
computing unit 24(a) at the originating participant 22(a) 
starts the commerce transaction by transmitting a request for 45 
the credentials of the intended recipient participants 22(b) 
and 22(c) who will be involved in the transaction (step 100 
in FIG. 6). The computing units 24(£>) and 24(c) at respective 
recipient participants 22(b) and 22(c) return their unique 
credentials to the originating computing unit 24(a) (step 102 50 
in FIG. 6). 

At step 104 in FIG. 6, the originating computing unit 
24(a) verifies the authenticity of the intended recipient 
participants. This verification is achieved by validating the 
digital signature of the trusted credential authority that is 
attached to the credential Recall from the registration pro- 
cess described above mat the credential binding server 
digitally signed each credential by encrypting the hash of the 
credential with the secret private signing key of the trusted 
credential authority. The originating computing unit 24(a) 
decrypts the hash by decrypting the encrypted hash using the 
binder's public key. If the decrypted hash matches, bit-for- 
fait, an independently and locally (trusted) hash of the 
credential, then the originating computing unit is assured 
both that the credential was created and signed by the trusted 
credential authority and has not been subsequently modified, 
and that the recipient participant is thereby authenticated. 



55 



public key from its key exchange pair of asymmetric keys. 
This public key exchange key was obtained from the first 
recipient's credential Similarly, the originating computing 
unit 24(a) encrypts the second symmetric key used to 
encrypt the instrument (Le„ payment instruction) and origi- 
nator's digital signature with the second recipient's (Le„ 
bank's) public key exchange key that was obtained from the 
first recipient's credential. Furthermore, sensitive or other- 
wise critical account information (such as a credit card 
account number) may be concatenated with the symmetric 
key, such that the account information also is encrypted with 
the recipient's (Le., bank) public key exchange key. This 
affords some longer term protection for the account 
information, should the symmetric key or algorithm ever 
become compromised. This step is represented as follows: 




60 



65 



At step 116, the originating computing unit 24(a) trans- 
mits the signed encrypted document and instrument over the 
communication system to the computing unit 24(h) at the 
first recipient participant 22(b), This is illustrated diagram- 
maticaUy in FIG. 2 by the document folder 36 and the 
instrument folder 38 being forwarded along communication 
path 40. The originating computing unit 24(a) also forwards 
the credential 32(a) of the originating participant 22(a) so 
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^ Det£SSaiy ****** to *"> « * e «»- participant 24(c) decrypts me 

At step 118. the computing unit 24rt>> at the fir« ™„,w C0I ? , ? c, f c »«™« (step 126). In our example, the second 

participant 24(fr) daSI S SS ? V P £ • CapiCD . t P®^** is a bank *»** decrypts the payment 

KSHLeo^fetttlS < maructions concerning how tee purchase? (Le.. &Z#_ 



r „. 24mM*qm 

The merchant computing unit 24(b) then decrypts the 15 0c^fcanmie*t>^^ 

yy u « y , as iouows. signature, which itself is a hash of 'Instnunenr, encrypted 

^ru^Cdocun^t')=docun^t^^^ irt with the private signing key of the originating participant At 

gssssSss • saigas 

decryption yields a hash that compares, bit-for-bit. with an At sta> 132 it HLH^KSk * 

independenUy, locally confuted hash of * . p . 11 1 determined whether there are any more 

fost^pient S^rS ^ht £ZTl t Jf P 81 ?^ ^olved in the transaction. If mere were more 

Notice that the method of this invention calls for the ^^P^W^^»e appropriate receipts 

? t0 . forward ^ ^ document ««i fflhe transaction is approved by the second reciment. 

mstrument to the first reagent participant In this manner. meaning that the bank detomh.es tha! iT^„ ST. 

=«««3 - sS==SS~ 

At step 124 in FIG. 8. the computing unit 24(W at the first A^l 9^°^^ Approaches 
redpient participant 22«>) iwSi^theeS^^JS^ ... AlthoUgh *? «rtion provides a description of 

2 by the instrument folder 38 being forwudedK f the tost SJTSST" ^ * . rCdUCC ? e Wma 

sary information to return coruscation « " ,2 1 ^ TT* 0 ^ ^ * accom - 

Stepsl26. 128. and 130 are simtatosLs lift i» a „H & ^ thn>U6h f trUSted ^ I"* For exam P lc - *e 
122 L were described ^SSff'^iZi ~ "* «*«"*« «** faCai » teS 
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In yet another embodiment the digital signature tech- 
nique used may be based on a technology other than public 
key. For example, the e Gamal digital signature technique, 
based on symmetric key cryptography, may be used. 

In yet another enfoodiment, the hash values from each of 
the documents) and commerce instruments) might be 
concatenated and then encrypted using the originator's pri- 
vate signature key. This has the advantage of computing 
only one public key encryption for multiple documents. 
Negotiated Off-line Encryption Architecture 
In a number of countries, encryption is subject to stringent 
regulation. Limitations may be applied to the algorithms as 
well as the key sizes used. In order to enable and ensure 
compliance with applicable regulations, it may be necessary 
for the communicating participants to negotiate or otherwise 
pre-establish the applicable parameters. In transaction com- 
merce electronically, the participants may not necessarily be 
in direct communication (e.g., they may be communicating 
via Electronic Mail). 

In such a situation, it is necessary for the parties to have 
a trusted way of mutually agreeing on the appropriate 
encryption algorithms and key sizes. Given that the parties 
have already established a mutually trusted party (the cer- 
tifying authority/binder), it follows that the binder can be 
trusted to provide an indicator for each participant on what ^ 
that participant's limitations are. An index which indicates 
the strongest algorithm and key size is placed on each 
participant's credential. 

When an originating participant encrypts a document or 
instrument for a specific recipient, that originating partici- 
pant takes his or her encryption index, along with the 
encryption index of the intended recipient, and uses the two 
values to look up the appropriate algorithm in a pre- 
established table. This table typically is established by the 
certifying authority for the version of the commerce protocol 
being used. 

The table typically contains the least common denomi- 
nator of encryption allowed between the two participants. 
This is particularly useful in international commerce, where 



structure that provides a convenient way to handle fields as 
self-defined entities. This affords the flexibility of adapting 
to the message content being sent. 

The tag-length-value (TLV) data structure 140 consists of 
three parts: an identifier field 142 (which is also known as 
the 'tag"), a length field 144, and a value field 146. The 
identifier field or tag 142 is a fixed-size field (e.g., 32-bit) 
that defines or identifies the commerce data contained in the 
package. Only those tags defined for the particular com- 
merce environment may be used. The length field 144 is a 
variable-sized field which contains a length of the commerce 
data contained in the package. The length field is preferably 
an exact byte count of the data contained in the value field 
146. For string fields that are NTJLL-tenninated, the count 
includes the NULL character. The value field 146 is a 
variable-sized field which contains the actual commerce data 
defined by the tag. 

There are many benefits resulting from this TLV data 
structure 140. First, the data structure allows data elements 
20 to be self-describing, which affords tremendous flexibility. 
Second, it renders the data elements conducive to C++ 
programming protocols. Another benefit is that the TLV data 
structure facilitates future protocol extensibility. Still 
another reason is mat the data structure enables backward 
compatibility. Further, the data structure permits customiza- 
tion of the contents of messages to fit the particular com- 
merce environment without impacting the basic architecture, 
technology and implementation of the electronic commerce 

system itself. 
Cryptography System Architecture 
Each computing unit 24(a)-24(c), as well as the creden- 
tial server 28, is equipped to perform cryptographic func- 
tions including encryption, decryption, digital signing, and 
verification. The computing units are programmed to 
execute a commerce application that facilitates the 
computerized, electronic commerce system. To sustain the 
security and authentication functions of the electronic com- 
merce system, the commerce application must be able to 
provide encryption, decryption, and digital signing. 



30 



35 



the regulations for one participant may differ from that of ^ Acccc dingly, each computing unit is implemented with a 
another. It is assumed (and the responsibility of the creden- CTy^eraphy system that supports the commerce applica- 



tial authority) that the algorithm/key size at the intersection 
in the table is one which is compliant with both countries 
involved in the transaction. , 
Tfcble 1 illustrates an example preestablished table used in 
a negotiation process between a first participant with one 
possible encryption index and a second participant with 
another possible encryption index. In this example, the 
encryption indices range from a value 'V which represents 



cryptography system that supports the commerce applica- 
tion with respect to these functions. 

FIG. 10 shows a computing unit 22 mat is used in the 
electronic commerce system of this invention. Computing 
45 unit 22 has a processor 150, a network I/O port 152, and a 
memory 154 which are all interconnected via an internal 
multi-bit bus 156. The network VO port 152 couples the 
computing unit 22 to the communication system employed 
in the electronic commerce system For example, the net- 



the inability to encrypt items to a value **2" which represents ^ wofk y0 ^ ^ might be in the form of a modem, network 
the ability to use rather secure encryption techniques. - - - ~ *--t.«"" 



TABLE 1 



No Order 
Encryption 
No Order 
Encryption 
No Order 
Encryption 



No Order Encryption No Order Encryption 



40 Bit RC4 
32 Bit RC4 



32 Bit RC4 
64 Bit RC4 
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Communication Data Structure 

FIG. 9 shows a data structure 140 used to carry each 
package that is exchanged between the participants, or 
between the participant and the credential trusted authority. 65 
It is used to encapsulate the messages and the message 
components. The data structure is a 4 tag-length-value" 



WWiW^*-*"^" j , 

card, or the like. The computing unit 22 also includes a data 
input apparatus 158 (eg., a keyboard, a mouse, a trackball 
a keypad, etc.) and a card reader 160 (e.g.. a smart card 
reader, a credit card reader, etc.) which are both operatively 
coupled to the bus 156. 

A commerce application 162 is stored in memory 154 and 
executable on the processor 150. The commerce application 
is a software program that is tailored to the particular 
commerce activity in which the participant is involved. 

The computing system 22 also has a cryptography system 
which supports the commerce application 162. In the illus- 
trated embodiment, the cryptography system is implemented 
in software that is stored in the memory 154 and executed on 
the processor 150. 

FIG. 11 shows the general architecture of the cryptogra- 
phy system, which is referenced with numeral 170. Cryp- 
tography system 170 has three layers: (1) a cryptographic 
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case, the commercTappUcaUon 162); (To^ or J!^, P 8 *"?""*- e CSPcan also exports import 

cryptographic service providers rrw mm^Cv!a^ , P 00 " 0 ena yptioD keys of the partidpants signing and 
which implement the ay^graphicS2oS ™S 5 ^^^^^^^that 
by CAPI to the apphcationr aid (3) one orZre a£ K&My avaJablc "> *<* non-encrypted format. 

allow the CSPs to communicate directly with a u»1Wa* 2f ° D , CC * e keys are used and 

one example implementation, this cr^S "Lm " C ° mplcted - howcver - me CSP destroys 

could incorporated into an operating system as a service 10 Thr ra> via ;<.„•*„... 

layer to provide cryptograph* services a7 h L^XS «. ' " 4 ls . s P ecificaI1 y ^ned to avoid exposing 

Wow in more dctaillvith SSct^SSs Vaf ^^^'^Private keys toany ^Ucation or uscTll,! 

TOe CAPI layer 172 itself S^SS^ltuk is to Sf™ ^ "* """^ aCCCSSiWe to ftc a PP U " 

selec* an appropriate CSP and verify £ SS^en ST S^ B W * B *** ^ 

the commerce application 162 needs a sequence of crvnto- .s E«T«. * , under orcumstances. In 

graphic functions to be performed (eTIn^vrnK" mliv • symmetac keys are permitted to leave the CSP 

decryption, signing), the Jk^M^Sm fZ. XnZt'T mt CXpOIted * a raw 

to acquire a context assorted with the a^c^CSP ^J** key P^vents the 

The CAPI 172 then loads the CSP and veX^UTn a PP 1 * atK>n ^f" 1 ever inadvertently mishandling keys in a 

ticity. Each CSP is dJ^S^TSSfiSSS 20 2Lf2 * CaUSC „. theni 10 to * * ose to 

aumorityCsuchasmelrcden™^ w ^ not <^.^. 

the use of its private encryption key. Thi* tfSJu JSS X 858181,5 ' handlcs " to tte various 

179 is graphically illustrated in FIG MwXrfSrS ^ ^ "J* 1 *" « ^"ed- These handles are made 

174 in memory 154. The SZgS^S'C^^ ™ f^^ 0 " ™ CAPI The appUcation 

172 can verify the authenticity oflhVcSP b? vSZ^S ^ ^ ^ ° Ver thenL However - *« keys 

digital signZe 179 ^SSSSSSSjti ^VS"" *?" iBd 

verification prevents introduction of a forei™ , a 1 T CSPs ^ provided with encryption/ 

CSP. The OU>I 172 aTo provides ^ZZ^^L wWch ""H* and datausing 

between the application and Ite^w^J^SJS^ « P"™ 00 ^ g , enerated <* Sported symmetric keys, and me 

never has dire^ a<xess LTc^otlvS^ ^ymmetac key pairs. More particularly, the CSP 174 has a 

CSP through the CAPL can only call to the symmetric key encryption/decryption device 190 which is 

The CAPI 172 is preferably implemented in softer, Ac !? '°, ****** decrypt n** 8 ^" (such as the corn- 
shown in the computing unit i^^^n Jmut* V^lS Z^T?**™^ ^ °« 8e - 
CAH 172 is stored in memorylS4 and executed on nZ. « J? ^° rt< ^ svmraetac keys. An asymmetric key 
cessor 150. The CAPI 172 J2w^ taST^nE en ^oa/decryption device 192 is also provided to encrypt 
module 181 to perform me Z!', (S venSa ^ ^ ^ s «ic keys using the key exchange^ 
tion. " 

The CSPs 174(a)-174(d) implement the r™*^^ ^ mentioned above, another function of a CSP 174 is to 

functionality request ^ iTf^lTl^St 40 ^1 ^"^^ ProtocoL In mis 

CSPs perform encryption key ^ageme" enc^iS J^T " Symmefiric kev <° encr yPt the 

decryption services, authentication anTS' £ "iSW that t en 2 yP ? on ^ *e P*Uc 

tasks, hashing routines, and digital dgninT^PreST! * v ^ °H g , S to fte mtcndcd "^P 16 " 1 - ™ s 

different CSP is configured to ^erfoC each Z i L I protocol pro^des a high degree of security by encrypting the 

techniques. 8 conventional loading computes the cryptographic digest of the data contained in 

For the key management task, the CSP 174 has a key ^"^^1^° ^ hashi *g «>- 

manager 182 (FIG. 10) that stores cenerates ^ ft « , translates the data according to a hashing 

encryption keys of any typl.Sudifg ^Sc^S ^ " faed - SiZe> often rcduccd - hash ^aluf 

graphic keys and asymmettc c^Shk^f t£c£ ^., ,S J^ PrcSCnt ^ Ve «° f . ,hC ^ Cryptographic 

stores the participant's sigoinTJSffiiStaSfc S S S""^"* ^""^ " ^ rcduce * e ^ of 

184 that is used to digitally ligTthe S3n ™S JSv WWch to Uni< l uc to ^ ««• 

commerce document L conXce UtiS Th^S J 3 fo^r^' aCC ° rdin8 ^ S ° mC has " 

c^rpartidpTts ° l ° ^ meSM8eS XDt by The CSP 174 also performs the task of digitally signing 

The CSP 174 has a symmetric key eencrator 188 whirh ^f-^ 8 ^ 6 ^.^ me f mtici P &at - The CSP has a signing 
generates the random M M SSiSKS «, JSLSL'J?* PK,VideS , a ^ Si8M,Ure ^ '° m ^ 

nc keys are preferably "sessional" and thus aeneratedfhr ,„^!„„ T computes the digital signature by 
each transaction. The CSP also imports ud e^ta^f "crypting a previously computed hash value output by the 
tion keys in their enoypted foJX'Xle^K; ^g^lZTJ^^T ^ "* 

msti^ntaredispatchedtomere^pient.Altona^ 
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packaging the cryptographic services in DLLs, it wdl be 5 *^^ n ^' V ^T nter confirmation/denial commands. 

%M^**^«*Z^™gtt lSSS?lW £ SS?« as to the state of 
considerations change without impacting the higher level Jhe PAH wo ^ ^ ^ ^ ^ 

applications. J . . . .. _„ „»~,ritv For examole the PAPI 176 can be configured to 

The CSPs might also be implemented in combinaUon with ^^^^^^^^^j^otus^L 

hardware. One example is " S^S^r^ha^some control over particular 

having a smart card reader and keys SftinuiunuzingthepossibiUty of amalicious 

cryptographic keys are stored and used y card key^e turm ^kcysinraw form, 

processor, so that they are not even exposed to sor^Ucatol a PP^°^ m "^Ltography system 170 wiU now 

Software attacks. Another example is a ^™*<*^, J^^^S^^^ V^li. Recall that each 

resistant hardware (such as a smart card) and a jpannd 15 ^^™f s e ^ uipped ^ a cryptography system 

computer (PC). Here, the PC might not be as trusted as the aTc^atinVcomputing unit and a recipient 

sewop box. and thus extra verification of the hardware and JJ-JJ^^JJ, oTisofssion. me operation 

terminal might be necessary. . w nT be described in two parts. A first part explains the 

Even with the protections enforced by the CAPUWand wuoe oes Jf" ttm mat takes place in the 

the CSPs 174. there is a danger that a Salg « i?2Si?uSt when preparing a message for 

5»£72^*ffi^^ 5S* c^^ri ^ivin, a M e (HOS. 

financial commitment on the part of the use* unbeknownst 25 15-16). ^ 

tote^ArtlBeuiipl.iite-W^fcg; A^stL 2w£nG. 12, uTapplication 162 supplies a 

the CSP to export all syinmetnc session keys to the CSF £ " to the CAPI 172 to be encrypted and 

the appucation writer, giving the appUcation writer the P™^^ le plamtext message is the commerce 

ability to read all of the user's encrypted data. ^^nVanTthe commerce tostrument The CAPI 172 

ToV* this ^JSO^jSSS St^rTS« CSPs 174 to perform the 

private appUcation program interfaces 0>APT, "JW-WJ * el ~l on and signing (step 202). In one implementation, 

(d) which permits the CSPs to interact™* the user through ^rj the appropriate DLL, and perform- 

an implementation-dependent user interface. Prior to oper- flus stcpe^ caUs such aVcaUs to begin and end the 

atingon a particular transaction, the PAPI 176 presents an ««V«« urf £&kX sign the result For purposes of 

^nation of the transacts to the user to assist the user in 35 encrj^n ^cu^^e oration will be described as if 

understanding the specifics of the transaction. Tlus prese^ ~ D ™ 7 ^g « !s Sable of performing bom the 

tation might be in the form of a textual sunimary displayed ^^"^^g^^nT 

ona nSr-ThePAPIenablesthe user toconto orrejej "J*"^? SSJSTU the CSP is established 

* c transaction by either attactung a digital autho- ^(^^fl^CAKWand selected CSP 174. The CAPI 172 

rizing the transaction, or avoiding sigmng to cance the 40 ^« n ^ e ^ _ f ft ^ m by validating the 

transaction. By involving the user each time > tutor ^gna- JgJ* SSStoSffl ^siglurTl79 attached to the CSP 

.ure is to be attached to a set of commerce <^""£ ^SSSSSJmSt^'* pubUc signature key 180 

instruments, the cryptography system mitigates the danger "l^tathTcAPI 172 (step 206). 

that a malicious appUcation will obtain sensitive interna- ^ £^3,3,53 the CAPI 172 passes the 

function provided by the PAPI 176 is context venficaUon „ ">™xJmeSetu> a cryptographic digest (step 210 in 
which the PAPI 176 verifies the authenticity of the ^ser or plamtext «k**J > ^W*S&*>»<* me transaction 
entity that is operating at the <^niputmg urn pnor to ^^^^ ^^^^^orcomroa^^- 
^gtm^accc^tothc^n^otL^ws^^ so ^J™™ passcdtothc PAni76(step212innG. 
PAPI rnight mediate a user login sequence to validate the ^J^^^JJJSerti a user interface which presents 
user. Alternatively, the PAPI 176 might be irnplememed in WJjJ" 1 J mTstep 214 in FIG. 13) and 

hardware, such as in combination with cart I reader 160 Jj^jJ^JJ ^1^1 wmmands which confirm, modify, 
which ^^^ D ^^^^ h ^^TS 6 t JS £^le wXxhl. affords an opportunity for the 
cardholder. The CSP 174 checks with the PAPI 17* to n or oe»y . to ^ &ansa ction at its inception, 

ascertain whether the appropriate authentication procedure £^^tX ^rtidpants. For example, the user 
have been met between the user and computing unit before ™™ order or after how he/she 

letting the commerce appUcation acquire a context Tlus * ^ed items. From a security 

context verification function is parUcularly on fr ^ S*veXs user interface ensures that the user is aware 

PC services or banking ATMs that require participation from 60 W^J^ ^ ^ he/she ^ authorizing it 
a person. ™ ,!,„.„._. authorizes the transaction, the PAPI 176 returns 

This aspect of the PAPI is implementation dependent If ™^o?to aTcSF 174(step 216 in FIG. 13). At step 
implementeTin a software-based PC the context * e originato^ 
tion might simply involve a check wim Ae PC operaUng 2W j*jCSPj pd. J «^ me ^ 

system for the identity of the user already ogged u. toa 65 ^cwTfhash) using ttw originator's private key of 

smart card terminal implementation, a full log* with PIN ^^f^^'S ^rrSTkey generator 188 
entry may be required 6 & * 
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generates a symmetric bulk data encryption key (step 220 in 
FIG. 13) and the CSP symmetric key encryption/decryption 
device 190 encrypts the message and the originator's digital 
sjpiature using the new symmetric encryption key (step 
222). At step 224, the CSP asymmetric key encryption/ 5 
decryption device 192 encrypts the symmetric encryption 
key using the key exchange public key of the intended 
recipient that is imported to the CSP. 

At step 226 in FIG. 14. the CSP 174 returns the signed and 
fh^^KJ 22™*" docuraem «"» commerce instrument to 10 
? u , } then onto thc oPPtfcation. At the same 

time, the CSP 174 can inform the user via the PAPI 176 that 
certain keys, such as the symmetric key, are being exported 
from the CSP in its encrypted format (step 228 in FIG 14) 
However, tiie asymmetric private keys of the signing and I€ 
Key exchange pairs are not exported from the CSP, but are 
permanently retained in confidence within the CSP. The 
commerce instrument and commerce instrument are then 
ready for transmission from the originating computing unit 
to the recipient computing unit as described above 
Part 2: Decryption and Verification 
The commerce application running at the recipient com- 
puting unit receives the signed encrypted document and 
msmiment and passes the package to its own cryptography 
system 170. Particularly, the encrypted document and tor- 
ment ju-e supplied to the CAPI 172 for purposes of being 25 
decrypted and verified (step 250 in FIG. 15). The CAPI 172 
selects the appropriate CSP or CSPs 174 to perform the 
decryption and verification (step 252 in FIG. 15). In this 
implementation, the appropriate CSP DLL is loaded and the 

£° n ^ Tforms a of calls to the DLL through the 30 
CAPL For discussion purposes, the operation will again be 
described as if the CSP 174 in FIG. 10 is capable of 
performing both the decryption and authentication functions 
at the recipient computing unit 
Communication is then established between the CAPI « 

r ?p?^ Sele ^ d ? P 174 (steP ^ * ^G. 15), and the 35 
CAPI 172 verifies the authenticity of the CSP 174 (step 256) 
Once the CSP is authenticated, the CAPI 172 passes the 
encrypted document and instrument to the CSP 174 for 
decryption (step 258). At step 260, the CSP asymmetric key 
encryption/decryption device 192 decrypts the symmetric 40 
encryption key using the recipient's private key exchange 
key 186 maintained in the CSP. The CSP symmetric key 
encryption/decryption device 190 uses the recovered sym- 
metric key to decrypt the message and originator's digital 

E£!S5 -° E^? 1 * sigDed ^yP^Phic digest (hash) 45 
I step inz in FIG. 15). 

At this point the CSP can verify the packet by decrypting 
the cryptographic digest (hash) using the originator's public 
signing key (step 264 in FIG. 16). If the decryption yields a 
result that compares bit-for-bit with an independently <n 
locally computed hash of the entire message, the Srticipant 
is assured that the packet came from the originator and was 
not subsequently altered For instance, in the electronic 
commerce system described above, the first recipient par- 
bcipant would be able to decrypt the commerce document, 
out decryption of the commerce instrument would yield 33 
meaningless information. 

rl^^^K™* 5 *** * «t«rned from the CSP to the 
CAPI 172 and then to the commerce application 162 (step 
266 in FIG. 16). After the process is completed, the CSP 
aestroys the symmetric encryption key for that session (step *> 

EXAMPLE IMPLEMENTATIONS 
The above discussion presents a general structure of an 
electronic commerce system. The following two cases pro- 65 
vide example implementations of the electronic commerce 
system in specific commerce environments. The first 
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example implementation is a credit card system and will be 
described with reference to FIGS. 17 and 18. The second 
examp e implementation is an interactive television system 
and will be described with reference to FIG. 23. In addition 
to these specific examples, the electronic commerce system 
can be implemented in a wide variety of commercial 
environments, including on-line services and debit or other 
banking card transactions. 

Example 1: Credit Card System 

FIGS. 17 and 18 diagrammatically illustrate an electronic 
credit card system 300 according to two different operation 
phases: a registration phase (FIG. 17) and an order and 
purchase processing phase (FIG. 18). The electronic credit 
card system 300 has several participants, including a pur- 
chaser 302, a merchant 304, an acquiring bank or acquirer 
306. an issuing bank 308, and a trusted authority or binder 
310. The financial roles of each participant in the commerce 
transaction are well-known and will not be described herein. 

Each participant is equipped with a computing unit, 
including a PC 312 at the purchaser and servcrs314, 316, 
and 318 at the merchant, acquirer, and binder, respectively 
Each computing unit is loaded with a credit card application 
and a cryptography system to support the credit card appli- 
cation with respect to its cryptographic needs. 

During the registration phase of FIG. 17, each participant 
requests and receives credentials from the binder 310 
^Binding" in this context means that the acquirer 306 is a 
known interface to an existing card payment system that is 
m use today; the merchant 304 is known to be able to accept 
credit cards for payment and deposit them with the acquirer 
306, and the purchaser 302 has a payment card known by the 
issuing bank 308 that issued the card. Credentials for the 
acquirer 306 and the merchant 304 are created by the binder 
310 as authorized by their responsible bank. Credentials for 
the purchaser are created by the hinder 310 as authorized by 
the purchaser's bank or authorized agent in the form of the 
card association. 

Cardholder credentials are created when the purchaser 
302 requests registration of a credit card. The purchaser 
enters card information (such as card number, expiration 
date, name on card) on the PC 312 to complete a registration 
application. The purchaser's computing unit also uses its 
cryptography system to generate the signing and key 
exchange pairs of public/private cryptography keys. The 
public keys are included in the registration packet 

Tlie purchaser's computing unit digitally signs the card 
registration packet and sends the packet over a communi- 
cate system to the binder's server 318. The binder's server 
318 validates the registration packet and creates a cardholder 
credential based on the information supplied by the pur- 
chaser. The cardholder credential includes the following 
information: 



Cardholder Credential 

1. Credential Serial Number. 

2. Cardholder Name. 

3. Hashed Account Number. 

4. Cardholder's Signing Public Key. 

5. Cardholder's Key Exchange Public Key. 

6. Credential Expiratioa 

7. Version of Credential Format. 

8. Encryption mcfex 



The "credential serial number" is a number generated by 
the binder to uniquely identify the credential. The "hashed 
account number" is created using a one-way hashing 
algorithm, such as the well-known SHA (secure hash 
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algorithm), which easily creates a unique hash value repre- 
sentative of the account number while rendering the regen- 
eration of the account number from the hash value compu- 
tationally infeasible. The hash guarantees that the credential 
is tied to a specific credit card. However, knowledge of the 
credential does not give any insight to the actual number of 
the credit card. The "credential expiration" field contains the 
date range mat the credential is valid as decided by the 
binder. L A 

The cardholder credential is signed by either the binder 
310 which might be the card association binder, or the card 
issuing bank binder in those cases where the card association 
has authorized the card issuing bank to do so. This credential 
is then sent back over the cornmunication path from the 
binder 1 s server 318 to the purchaser's computing unit 312 as 
indicated by the credential 320 in FIG. 17. 

Notice that the acquirer 306 registers with the binder 310 
for both itself and on behalf of the merchant 304. In the 
credit card context, the merchant 304 participates based 



Acquirer Credential 
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1. Credential Serial Number. 

2. Acquirer Name. 

3. Acquirer's Signing Public Key 

4. Acquirer's Key Exchange Public Key 

5. Credential Expiration. 

6. Version of Credential Format 

7. Acquirer BIN 

8. Card Brand Accepted 



The acquirer credential is digitally signed by the credit 
card association's credential binding authority. 

Turning now to the order and purchase processing phase 
of FIG 18, the credit card system implemented with the 
electronic commerce system of this invention involves the 
communication paths shown in solid lines. The electronic 
credit card system of this invention facilitates the document 
and instrument interchange among the purchaser 302, mer- 



credit card context, the merchant paracipa^ ^ ^ ^3^^^ interchange among uie purcntu>w 
upon the authority of the merchant's financial instituuon. 20 ^ m ^ mvdrct 306 . The dotted lines represent 
which is the acquirer 306 in this case. As a result there is commerce processes implemented and operating by the 
information known only to the acquirer that will be included cjd&nng payment card authorization and settlement systems 



information known only to the acquirer 

in the merchant's credential. The binder will create both 
credentials 322 and 324 for the merchant and acquirer and 
send both to the acquirer, which then passes the merchant s 
credential 322 onto the merchant. Alternatively, it 
authorized, the acquirer can create the merchant's credential 
directly. 

The merchant's credential is conceptually similar to the 
cardholder credential. There are eleven fields contained in 
the merchant's credential, with the first six fields being 
analogous to fields in the cardholder credential. The mer- 
chant's fields are: 



Merchant Credential 
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1. Credential Serial Number. 

2. Merchant Name. 

3. Merchant's Signing Public Key 

4. Merchant's Key Exchange Public Key 

5. Period of Credential Validity. 

6 Version of Credential Format . . 

7*. Acquirer's Key Exchange Public Key (for payment mstmctoons) 

8. Card Brand Accepted 

9. Acquirer BIN 

10. Merchant O 

11. Encryption Index — — 

The last four fields are used to help define the business 
relationships and responsibilities that are inherent m foe 
credit card model. The "acquirer's key exchange public key 
is included to enable encryption of the payment instruction 
by the purchaser such that only the acquirer may decrypt it 
The acquirer's public is key could be distributed directly o 
the purchaser via the acquirer's credential but is preferably 
included in the merchant's credential in the interest of 
efficiency and is in recognition of the special business 
relationship between the acquirer and the merchant. 

The "card brand accepted" field indicates the particular 
card brand (e.g.. Visa® or MasterCard®) that can be 
accepted by the merchant. The "acquirer BIN" is fee iden- 
tifier of the acquirer as used by the card association. The 
•'merchant ID" is the identifier of the merchant as used by 
the acquirer. The cardholder's credential is signed by the 
card association binder or the acquirer if authorized by the 
binder. 

The acquirer credential contains items similar to the 
purchaser or merchant credentials, including the following: 



existing payment card authorization and settlement systems 
in use today. As noted above, the purchaser PC 312, mer- 
chant server 314. and acquirer server 316 all execute a credit 
card order and payment application, and a cryptography 
system, to meet the security, privacy, integrity, and authen- 
ticity needs of this particular commerce system. During the 
order and processing phase, there is no active participation 
on the part of the binder 310. 

The purchaser 302 creates a commerce document in the 
form of a goods and services order (GSO) and a commerce 
instrument in the form of a purchase instruction (PI). 
GSO and PI are configured in packets using the tag-lengm- 
value data structure described above with reference to FIG. 
9 An example GSO contains a name of the payee 
(merchant), an authorized amount a unique transaction ID. 
purchaser's name and address, an order expiration, and an 
order form. An example PI includes the payee name 
(merchant), the authorized amount, the unique transaction 
ID, a GSO message digest, a card expiration, and order 
expiration. . 

The GSO and PI are digitally signed by the purcte 
using the appropriate cryptographic service provider (OP) 
in the crSography system. TheGSO and PI «to 
encrypted with a syrnmetric cipher using two different, 
randomly selected synunetric keys. The GSO data requires 
relatively less privacy (in comparison to the PI) becauseit 
contains less financial informatioiL Thus, the GSO can be 
encrypted with a symmetric key of comparatively less 
strength, such as a key devised by the known RC4 algorithm 
with a key length of 40 bits. On the other hand, the PI 
contains more financial information and warrants higher 
privacy. The PI is encrypted with a DBS syrnmetric key 
having a key length of 56 bits. 

The symmetric keys for the GSO and PI are next 
encrypted with the key exchange public keys of the mer- 
chant and acquirer, respectively. The GSO symmetric key is 
less stringently protected by a relatively smaller 768-bit 
RSA public key, whereas the PI symmetric key is more 
strongly protected using a 1024-bit RSA key. 

The signed encrypted GSO 330, signed encrypted PI 332, 
and the cardholder credential 320 are packaged and sent to 
the merchant over a communication network 334. An 
example network 334 include a telephone network. 

The merchant server 314, using its cryptography system, 
decrypts the GSO 330 using its own key exchange private 
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Create Credential 
Registration Request 
Process Credential 
Registration Response 
Create Transaction 



Process Transaction 
Receipt 



key. The merchant server 314 then uses the purchaser's 
public signing key received in the cardholder credential 320 
to verify the purchaser's digital signature on the GSO. This 
assures the merchant that the purchaser is authentic and the 
order is valid. Meanwhile, unable to decrypt the PI 332 the 
merchant server 314 leaves the PI in its encrypted form. 

To consummate the transaction, the merchant needs to 
secure funds from the purchaser to pay for the ordered items. 
Accordingly, the merchant server 314 sends the still 
encrypted PI 322 and the purchaser's credential 320 onto the 
acquirer server 316 using the same or another communica- 
tion network 336. An example network 336 might be an 
ISDN network which links the merchant and acquirer. 

Using its cryptography system and own private key 
exchange key, the acquirer server 316 decrypts the PI 332. 
The acquire server 316 then uses the purchaser's signing 
public key received in the purchaser's credential 320 to 
verify the purchaser's digital signature on the PL 

The PI is channeled through the existing payment card 
authorization system to validate the availability of funds for 20 
the purchaser. More particularly, the acquirer 306 uses the 
existing credit card network 338 to contact the issuing bank 
308 that issued the credit card and handles that credit 
account for the purchaser 302. If sufficient credit or funds are 
available, the issuing bank 308 returns an authorization 
response over the network 338 to the acquirer 306. The 
authorization response is then digitally signed by the 
acquirer 306 and encrypted using the key exchange public 
key of the merchant The response 340, along with the 
acquirer's credential 324, is sent over the communication 
network 336 to the merchant server 314. 

The merchant server 314 uses its cryptography system 
and private key exchange key to decrypt the response 340 
and the acquirer's public signing key received in the acquir- 
er's credential 324 to verify the response. Given the signed 
authorization, the merchant knows that payment is guaran- 
teed. The merchant can now fill the order and ship the items 
to the purchaser. The merchant server 314 then generates a 
purchase receipt 342, digitally signs the receipt and 
encrypts it using the purchaser's public key exchange key. 
TTie purchase receipt 342 is sent from the merchant server 
314 over the communication network 334 to the purchaser's 
PC 312 which then decrypts and verifies the receipt 

At the close of the merchant's business day, the merchant 
304 requests payment for all approved payments for which 
goods have been shipped. The merchant server 314 transmits 
a file of all such payment transactions processed that day to 

the acquirer for decryption and deposit into the normal draft 

clearing and settlement system used today. The acquirer <n r DCCSsC „ 
pays the merchant and then settles its account with the ******** Rcs p° d * 
issuing bank using the existing credit card system 338 and 
the issuing bank bills the purchaser in due course. 

FIGS. 19-22 illustrate more particularly the use of the 
cryptography system as a lower-level service provider to an 
operating system application mat is tailored for the pur- 
chaser (FIG. 19), the merchant (FIG. 20), the acquirer (FIG 
21). and the binder (FIG. 22). For convenience purposes, 
only the CAPI layer of the cryptography system is illustrated 
in these Figures. 

As shown in FIG. 19, a purchaser application 350 running 
at the purchaser PC 312 calls functions in a purchaser 
application program interface (API) 352 which then calls 
functions in the CAPI 172 of the cryptography system. The 
purchaser application 350 might request, for example, cre- 
ation of a registration request, creation of a transaction or 
processing of a transaction receipt. To create a registration 
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request during the registration phase, the purchaser appli- 
cation 350 submits the binder credential and the purchaser's 
account number and the purchaser API returns a credential 
registration request This request is properly signed and 
encrypted by the underlying cryptography system in the 
manner described above with respect to FIGS. 10-14. As 
another example, to create a transaction, the purchaser 
application 350 passes a charge slip, a summary, the mer- 
chant credential, a transaction amount purchase terms, and 
transaction details to the purchaser API 352. which then 
returns a transaction and an identifier for that transaction. 

Table 2 shows an example set of API function calls, listing 
input terms which are supplied from the purchaser applica- 
tion to the purchaser API and returned items sent back from 
the purchaser APL 

TABLE 2 



Pmriwsfrr \PI Function Calls 
Input Terms Returned Terms 



Binder Credential 
Account Number 
Registration Response 

Charge Slip 
Summary 

Merchant CredentiaJ 
Transaction Amount 
Purchase Terms 
Transaction Details 
Receipt 



Request 



Transaction 
Transaction Identifier 



Amount 

Transaction Identifier 
Merchant Name 
Merchant Message 
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With respect to FIG. 20, a merchant application 354 
running at the merchant server 314 calls functions in a 
merchant API 356 which then calls functions in the CAPI 
172 of the cryptography system. Table 3 shows an example 
set of function calls for the merchant APL 

TABLE 3 



Function 



Merchant A PI Function Calk 
Input Terms Returned Terms 



Create CredentiaJ 
Registration Request 
Process Credential 
Registration Respc 
Process Transaction 



Binder Credential 
Account Number 
Registration Response 

Transaction 



Request 
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Create Transaction 
Authorization Request 



Process Transaction 
Authorization 



Transaction Auth. 
Amount 

Transaction Identifier 
Charge Slip 
Acquirer Credential 
Transaction Auth. 
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Create Transaction Authorized Amount 



Charge Slip 
Transaction Amount 
Purchase Terms 
Transaction Identifier 
Transaction Details 
Purchaser CredentiaJ 
Transaction Auth. 
Request 



Transaction Auth. 
Identifier 

Authorized Amount 
Transaction Auth. 
Response Code 
Acquirer Message to 
Purchaser 
Receipt 
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TABLE 3-continued 
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TABLE 5 -continued 



Function 



M^rrW API Function Calls 
Input Terms Returned Terms 



^ Function 



Input Terms Returned Terms 



Receipt 



Transaction Identifier 
Merchant Name 
Merchant Message 
purchaser Credential 
Acquirer Message to 
Purchaser 



Registration Response 



10 



With respect to FIG. 21. an acquirer application 36© 
running at the acquirer server 316 calls functions in an 
acquirer API 362 which then calls functions in the CAPI 172 
of the cryptography system. Table 4 shows an example set 
of function calls for the acquirer API. 

TABLE 4 



Requester Name 
Requester Account 
Number 
Binder Name 
Validity Period 
Requester Signature 
Public Key 
Requester Key 
Exchange Pub. Key 
Credential Identifier 



Response 

Requester Credential 
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Acquirer API Function Calls 



Function 



Input Terms 



Returned Terms 



Create Credential Binder Credential 

Registration Request Account Number 

Process Credential Registration Response 
Registration Response 

Process Transaction Transaction 

Authorization Request Authorization Request 



Create Transaction 
Authorization 



Transaction Auth. 
Identifier 

Transaction Identifier 
AiMhorized Amount 
Purchaser Credential 
Merchant Credential 
Trans. Authorized 
Response Code 



Request ' 



Transaction Auth 
Identifier 

Transaction Identifier 
Transaction Amount 
Transaction Auth 
Amount 

Purchaser Name 
Purchaser Account 
Number 

Merchant Account 

Number 

Summary 

Purchaser Credential 
Mnxh*"* Credential 
Transaction Auth. 
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40 



With respect to FIG. 22, a binder application 364 nrniung 
at the binder server 318 calls functions in a binder AH 366 
which then calls functions in the CAPI 172 of the cryptog- 
raphy system. Table5 shows an example set of function calls 
for the binder APL 



TABLE 5 



p frrier API F unction Calls 



Function 



Input Terms 



Returned Terms 



Process Credential 
Registration Request 



Request 



Create Credential Credential Type 



Requester Type 
Requester Name 
Requester Account 
Number 

Requester Signature 
Public Key 
Requester Key 
Exchange Pub. Key 
Credential Regis. 



Example 2: Interactive Entertainment System 
FIG 23 (UagrammaticaUy illustrates an interactive tele- 
vision'flTV) system 400 that implements the electronic 
20 conimerce system according to ™^ a f^J f ^™Zt 
tion. The participants include a sutecriber 401 a merchant 
404 an acquire 4^ and a cable operator 408. Hie subscriber 
402 is equipped with a computing unit in the form of a 
set-too box (STB) 412. The merchant and acquirer each have 
fserTerTl4 and 416, respectively, and the cable operator 
25 408 is equipped with a headend server 418. Each coir^utxng 
3 is loaded with an ITV cornmerce application and a 
crvptoeraphy system to satisfy the security, privacy, 
ffl^ authenticity aspects of the ITV system. In this 
imp&tation, the ITV conimerce appUcation can be 
downloaded from the headend server to fce OTs a 
requested, rather than remaining resident at the SIB. Tte 
cryptography system, however, would reside and be execut- 
able at the STB. 

The subscriber STB 412 and merchant server 414 are 
interconnected with the headend server 418 via an interac- 
tivTnetwork structure, which is represented by the network 
cloud 420. One example implementation of the networ* 
sSreis a hybriTfiber-optic/cable distribution system 
employing digital switching technologies such as asynchro- 
X Set mode (ATM) for bi-directional commumca- 
tions between the headend and individual ^bs^r/ 
merchants. This multi-tier distribution system includes a 
high-speed, high-bandwidth fiber optic cable coupled 
headend and many regional distribution nodes. 
45 Each distribution node is then connected to multiple set-top 
boxes within the region via conventional home entry hnes 
such as twisted-pair telephone lines or coaxial cable. As an 
example, a single headend might service 250,000 or more 
subscribers, and each regional distribution node might sup- 
50 port approximately 1200 subscribers. As technology contm- 
uTto improve, parts of the ITV network structure can be 
replaced with wireless forms of communication, such as KF 
communication or satellite communication. 
In this implementation, the cable operator 408 might 
53 perform several roles. The headend server 418 performs its 
traditional tasks of providing video content programs to the 
subscribers and facilitating communication over the network 
420. The cable operator 418 might also operate as the 
binding authority which certifies all subscribers connected to 
60 the ITV network, including the purchasing subscriber and 
the merchant subscriber. In this fashion, the subscn^ers 
submit registration applications over the ITV network 320, 
and receive credentials from the headend server 418. The 
cable operator 418 might also function as a financial lnsti- 
65 tution analogous to an issuing bai^ 

wherein the cable operator bills and collects money from me 
subscribers. 
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During a purchasing transaction, the purchaser subscriber In compliance with the statute, the invention has been 
40Z creates a commerce document in the form of an elec- described in language more or less specific as to structure 
tronic purchase order (PO) 422 and a commerce instrument and method features. It is to be understood, however, that the 
ui the form of a purchase instruction (PI) 424. The PO and invention is not limited to the specific features described 
m ug^y signed by the purchaser subscriber STB, 5 since the means herein disclosed comprise exemplary forms 
encrypted with selected symmetric keys that are then of putting the invention into effect. The invention is 
enoTpted with the public key exchange keys of the mer- therefore, claimed in any of its forms or modifications within 
chant 4W and acquirer 406, respectively. The signed the proper scope of the appended claims appropriately 
encrypted PO 422. signed encrypted PI 424, and a subscriber interpreted in accordance with the doctrine of equivalents 
credential 426 are packaged and sent over the interactive and other applicable judicial doctrines, 
network 420 to the headend server 418. which then redirects We claim: 

it to the merchant subscriber 404. 1. A cryptography systemto support an application requir- 

The merchant 404 decrypts and verifies the PO 422. The ing cryptographic functions, the cryptography system corn- 
merchant 404 then sends the encrypted PI 424 and the prising: 

purchaser subscriber's credential 426 onto the acquirer 406 a cryptographic application program interface (CAPI) to 
via a separate communication network 428. The acquirer interface with the application and handle its requests 

server 416 decrypts and verifies the PI 424. The acquirer for a cryptographic function; 

determines whether the funds exist to consummate the at least one cryptography service provider (CSP) inde- 
purchase and, if so returns a signed authorization receipt 430 pendent from, but dynamically accessible by, the CAPI; 

to the merchant. The merchant then fills the order and sends the CSP providing the cryptographic function requested 
a signed receipt 432 to the subscriber. 20 by the application, the CSP also managing and protect- 

Once the goods are shipped, the merchant 404 requests in g at least one encryption key used in the crypto- 

and receives payment for the goods from the acquirer. The graphic function to prevent exposure of the encryption 

acquirer then settles the account with the purchaser's issuing H cy m a DOn " eDcr yP ted form to the CAPI and applica- 

bank. or the cable operator 408 if authorized to perform that c tion; and 

function. 25 a private application program interface (PAPI) to interface 

The example embodiments illustrate several benefits of CSP a uscr ' . the enabUn 8 thc user to 

the electronic commerce system. First, each document or £££ COnfixm " 0r reject re 4 uested cryptographic 

instrument is digitally signed and encrypted by an oricinat- >» A u * .* j • i 

ing participant This insures that thedLment and SL M n^S^^T^TTf^^t^S^ 
ment will be decrypted and the signature independently 30 Ssted tutt * * 

verified only by the intended recipient participant. The * a . _llu . 

originating participant and was not sub^uenu^terL * ^^graphysyst^ as reatedin claim 1 wheremthe 

Another benefit i, that the encrypted .2 signed pledges ^ ^ ' * °' 
are independent entities that can be transported by any 5. A cryptography system as recited in claim 1 wherein the 
commumcation protocol and system. This allows the elec- (^Pstoris at lek one encryption key. 
fronic coerce system to operate over the communication «, 6. A cryptography system as recited in claim 1 wherein the 
system that already exists between the participants, such as CSP generates the encryption key. 
phone network! j. on-line services networks, wide area 7. A cryptography system as recited in claim 1 wherein the 
networks, interactive television networks, etc. CSP desu-oysto encryption key following its use. 

Another advantage is that the encryption attributes can be 8. A cryptography system as recited in claim 1 wherein the 
vaned according to document type. In the credit card 45 CSP assigns a handle to the encryption key, the handle being 
example, the GSO and PI are encrypted using independently made available to the application through the CAM while 
specifiable cryptographic algorithms and strengths (often the encryption key remains unavailable to the application 
expressed in terms of key sizes or bit count). Regulatory and and die CAPI. 

legal entities can therefore set the standards of allowable 9. A cryptography system as recited in claim 1 wherein, 
encryption for each document or instrument within a par- so when the application requests encryption of a message, the 
hcular commerce system. The electronic commerce system CSP hashes at least some data contained in the message, 
according to an aspect of this invention can then be flexibly 10. A cryptography system as recited in claim 1 wherein 
adapted to conform to those standards. In this manner, the the CSP is implemented in software as dynamically linked 
electronic commerce system can be used in a wide variety of libraries. 

commerce activities, and support the particular regulatory 53 11. A cryptography system as recited in claim 1 wherein 
and legal cryptographic standards imposed for each different the CSP exports the encryption key only in an encrypted 
activity. Furthermore, by implementing the cryptography form. 

JESS" .^nT^L °^ t0graphiC Savice providers 12- A cryptography system as recited in claim 1 wherein. 
(CSPs) as DLLs, the electronic commerce system can when the application requests encryption of a message, the 
respond quickly to regulatory induced changes simply by « CSP encrypts the message using a symmetric encryption key 
replacing the DLLs without impacting the higher level and then encrypts the symmetric encryption key using a 
application software. public tey ^ „ u^,^ pair of ^ vate ^ d ^ 

The electronic commerce system has another benefit in encryption keys, 
that it can be used in a complementary fashion with existing 13. A cryptography system as recited in claim 1 wherein 
commerce systems, such as the credit card payment card es the CSPmanages at least one asymmetric pair of private and 
authorization and settlement system, that are already in place public encryption keys and permanently retains the asym- 
toda y- metric private encryption key in confidence. 
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14. A cryptography system as recited in claim 1 further 
comprising multiple CSPs to perform various ones of the 
cryptographic functions, said cryptographic functions 
including encryption, decryption, signing, and verification. 

15. A cryptography system as recited in claim 1 wherein 5 
the PAPI presents, to the user, an explanation of the cryp- 
tographic function being requested by .the application. 

16. A cryptography system as recited in claim 1 wherein, 
when the application requests a digital signature on a 
message, the PAPI presents an opportunity for the user to 1Q 
confirm or deny attaching a digital signature before the CSP 
digitally signs the message. 

17. A cryptography system as recited in claim 1 wherein 
the PAPI verifies the user' s authenticity prior to enabling the 
user access to the application through the CSR 

18. A cryptography system as recited in claim 1 wherein 15 
the PAPI enables data entry from the user. 

19. A cryptography system as recited in claim 1 wherein, 
when the application requests use or exportation of a par- 
ticular encryption key, the PAPI selectively notifies the user 
when the particular encryption key is to be used or exported. 20 

20. In a computer system having a processing unit and a 
computer-readable medium, a computer-implemented cryp- 
tography service provider stored on the computer-readable 
medium for execution on the processing unit as part of a 
cryptography system used to support a computer executable 25 
application requiring encryption or decryption of electronic 
messages to be sent or received by a user, the cryptography 
service provider comprising: 

a key manager to manage encryption keys used to encrypt 
messages and to prevent the encryption keys from 30 
being exported in a non-encrypted form from the 
cryptography service provider; 

an encryption/decryption device to encrypt or decrypt 
messages using the encryption keys; and 

the cryptography service provider being configured as a 55 
dynamic linked library, software module which is 
dynamically accessible as needed by the application to 
receive a plaintext message and to return an encrypted 
message, or to receive an encrypted message and to 
return a plaintext message, without exposing the 40 
encryption keys in their non-encrypted form to the 
application. 

21. A cryptography service provider as recited in claim 20 
wherein the encryption/decryption device encrypts indi- 
vidual messages using a symmetric encryption key and then 45 
encrypts the symmetric encryption key using a public key 
from an asymmetric pair of private and public cryptographic 
keys. 

22. A cryptography service provider as recited in claim 21 
wherein the key manager exports the symmetric encryption 50 
key only in an encrypted form. 

23. A cryptography service provider as recited in claim 20 
wherein the key manager manages at least one asymmetric 
pair of private and public cryptographic keys and perma- 
nently retains the asymmetric private cryptographic key in 55 
confidence. 

24. A cryptography service provider as recited in claim 20 
where in the key manager stores at least one unique encryp- 
tion key. 

25. A cryptography service provider as recited in claim 20 60 
further comprising a key generator to produce the encryption 
keys used to encrypt the message. 

26. A cryptography service provider as recited in claim 20 
wherein the key manager assigns handles to the encryption 
keys which are made available to the application, while 65 
maintaining the encryption keys themselves unavailable to 
the application. 



27. A cryptography service provider as recited in claim 20 
further comprising a hashing calculator to hash at least some 
data contained in the messages. 

28. A method for supporting cryptographic functions 
requested by an application, the method comprising the 
following steps: 

supplying a request for a cryptographic function to a 

cryptographic application program interface (CAPI); 
selecting a cryptography service provider (CSP) to per- 
form the desired cryptographic function; 
establishing communication between the CAPI and the 
CSP; 

verifying an authenticity of the CSP; 
performing the cryptographic function at the CSP using at 

least one cryptographic key; and 
preventing exposure of the encryption key in a non- 
encrypted form to the CAPI or application. 

29. A method as recited in claim 28 wherein the perform- 
ing step comprises performing a cryptographic function 
selected from a group comprising encryption, decryption, 
digital signing, and verification. 

30. A method as recited in claim 28 further comprising 
presenting information concerning the requested crypto- 
graphic from the CSP through a private application program 
interface (PAPI) to a user to enable the user to observe, 
confirm, or reject the requested cryptographic function. 

31. A method for encrypting a message comprising the 
following steps: 

supplying a plaintext message to a cryptographic appli- 
cation program interface (CAPI); 
selecting a cryptography service provider (CSP) for 

encrypting the message; 
establishing communication between the CAPI and the 
CSP; 

verifying an authenticity of the CSP; 
passing the plaintext message from the CAPI to the CSP; 
encrypting the message at the CSP using an encryption 
key maintained by the CSP to produce an encrypted 
message; and 

passing the encrypted message from the CSP back to the 
CAPI without exposing the encryption key in its non- 
encrypted form. 

32. A method as recited in claim 31 wherein the encrypt- 
ing step comprises the following steps: 

encrypting the message with a symmetric encryption key; 
and 

encrypting the symmetric encryption key with a public 
key from an asymmetric pair of private and public 
cryptographic keys. 

33. A method as recited in claim 32 wherein the encrypt- 
ing step comprises the step of passing the encrypted sym- 
metric encryption key to the CAPI along with the message. 

34. A method as recited in claim 31 wherein the verifying 
step comprises the following steps: 

attaching a digital signature of a certified trusted authority 

to the CSP; and 
validating the digital signature to authenticate the CSP 

35. A method as recited in claim 31 further comprising the 
step of attaching a digital signature of the cryptography 
system to the message. 

36. A method as recited in claim 31 further comprising the 
step of storing within the CSP at least one unique encryption 
key. 

37. A method as recited in claim 31 further comprising the 
step of generating within the CSP the encryption key used to 
encrypt the message. 
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38. A method as recited in claim 31 further comprising the 
step of destroying the encryption key following its use. 

39. A method as recited in claim 31 further comprising the 
following steps: 

assigning a handle to the encryption key; and 5 
making the handle available to the CAFI while maintain- 
ing the encryption key in confidence within the CSP. 

40. A method as recited in claim 31 further comprising the 
step of hashing within the CSP at least some data contained 

in the message. 10 

41. A method as recited in claim 31 further comprising the 
following steps: 

passing an explanation of the message to a private appli- 
cation program interface (PAPI) used to interface the 
CSP with a user, and 15 

presenting the explanation to the user. 

4Z A method as recited in claim 41 further comprising the 
step of verifying at the PAH an authenticity of the user prior 
to presenting the explanation of the message. 

43. A method as recited in claim 41 further comprising the 
step of enabling data entry from the user through the PAPL 

44. A method as recited in claim 41 further comprising the 
step of selectively notifying the user via the PAPI when a 
particular encryption key is to be used. 

45. A computer-readable medium having computer- 25 
executable instructions for performing the steps in the 
method recited in claim 28. 

46. A computer-readable medium having computer- 
executable instructions for performing the steps in the 
method recited in claim 31. 



34 



^fJ , *^, computcr '. rcadab,c medium having a computer- 

SCS^S?" for implementin8 aay p^ 

a cryptographic application program interface (CAPI) 
configured as a software module to interface with a 
computer-implemented application and to handle 
j^ uests fr °m the application for a cryptographic func- 

at least one cryptography service provider (CSP) config- 
ured as a software module independent from, but 
dynamically accessible by. the CAPI; 

the CSP providing the cryptographic function requested 
by the software application, the CSP also managing and 
protecting at least one encryption key used in the 
cryptographic function to prevent exposure of the 
encryption key in a non-encrypted form to the CAPI 
and software application. 

48. A computer-readable medium as recited in claim 47 
further corr^rising a private application program interface* 
::^^? nfigured w a software module independent from 
£ C r^!l d ^ ^ PAPI configured to interface 
the CSP with a user and enable the user to observe, confirm, 
or reject the requested cryptographic function. 

49. A computer-readable medium as recited in claim 47 
wherein: 

the CSP module is digitally signed with a digital signature 

of a certified trusted authority; and 
the CAFI module verifies an authenticity of the CSP when 

accessing the CSP by validating the digital signature of 

the certified trusted authority. 
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